nerdctl: una alternativa ligera a Docker sobre containerd

javi
Contenedores de envío representando arquitectura de software

Durante años “Docker” fue sinónimo de “contenedores”. Pero la arquitectura real debajo ha cambiado: containerd es hoy el runtime de contenedores estándar en Kubernetes y en muchas otras plataformas, y Docker (el demonio) es solo una de las capas que lo envuelve. nerdctl ofrece una alternativa: la interfaz familiar de Docker pero hablando directamente con containerd.

El contexto: cómo llegamos aquí

Hasta 2020, Kubernetes ejecutaba contenedores a través de Docker Engine. En 2020 anunciaron la deprecación de dockershim (el shim que traducía peticiones de K8s a Docker), y en 2022 la retiraron. Desde entonces, el runtime estándar en clusters K8s es containerd directamente, sin Docker Engine en medio.

containerd existe desde 2014 como subproyecto de Docker, luego donado a la CNCF. Es más pequeño y especializado: solo gestiona ciclo de vida de contenedores e imágenes. No incluye build, UI, red de Swarm ni las otras capas que Docker Engine añadía.

El problema: si container engine = containerd, ¿qué usas en línea de comandos? crictl es demasiado bajo nivel (pensado para Kubernetes, no humanos). Aquí entra nerdctl.

Qué es nerdctl

nerdctl es un CLI compatible con Docker (sí, muchos comandos son idénticos: nerdctl run, nerdctl ps, nerdctl build) que habla con containerd directamente. Está desarrollado por el propio equipo de containerd y distribuido oficialmente.

Características que incluye y Docker Engine no tiene nativamente:

  • Soporte rootless por defecto. Corre containerd y sus contenedores como usuario sin privilegios, sin setup adicional.
  • Imágenes encriptadas y firmadas. Integración con ocicrypt y cosign para cadena de suministro segura.
  • Lazy-pulling. Con stargz-snapshotter, arranca contenedores antes de descargar toda la imagen — útil para imágenes grandes.
  • Soporte CNI nativo. Las redes se configuran con plugins CNI estándar, los mismos que usa Kubernetes. Reusa tu conocimiento.

Cuándo tiene sentido cambiar

Tres escenarios donde nerdctl supera a Docker Engine:

  • Desarrollo en máquinas que ya ejecutan containerd. Si tu entorno local tiene k3s o Docker Desktop usando containerd internamente, usar nerdctl elimina la capa de Docker Engine. Menos memoria consumida, menos procesos.
  • Coherencia con producción K8s. Si tu cluster de producción usa containerd, desarrollar con el mismo runtime evita sorpresas sutiles (diferencias de storage drivers, gestión de red, cgroups).
  • Entornos restringidos. Rootless containerd + nerdctl funciona donde Docker Engine no: hosts donde no puedes dar privilegios de root.

Casos donde Docker Engine sigue ganando

Por otro lado, algunas áreas donde Docker todavía lleva ventaja:

  • Ecosistema de herramientas. IDEs, plugins, extensiones de Docker Desktop — todo eso asume Docker Engine. nerdctl cubre casi todos los comandos pero no toda la integración.
  • Docker Compose. nerdctl tiene nerdctl compose pero sigue por detrás en compatibilidad con compose v3.8+ y features avanzadas (profiles, extensions).
  • Docker Swarm. Si usas Swarm como orquestador, no hay alternativa — nerdctl no implementa Swarm mode.
  • Curva de aprendizaje del equipo. Si todo el equipo domina Docker, cambiar solo por “mejor tecnología” raramente compensa el coste de transición.

Instalación y primeros pasos

En un Linux con containerd ya instalado (vía apt/yum o como parte de K8s node):

# Descarga binario (último release)
wget https://github.com/containerd/nerdctl/releases/latest/download/nerdctl-full-linux-amd64.tar.gz
tar -xzf nerdctl-full-linux-amd64.tar.gz -C /usr/local/

# Primer contenedor
nerdctl run --rm hello-world

# Ver imágenes
nerdctl images

# Ejecutar detached
nerdctl run -d -p 8080:80 nginx

La sintaxis es familiar para cualquiera que venga de Docker. Para usar rootless:

containerd-rootless-setuptool.sh install
systemctl --user start containerd
nerdctl run --rm hello-world   # ahora corre como tu usuario, sin sudo

nerdctl vs podman

podman es otra alternativa a Docker CLI, particularmente popular en entornos Red Hat. Diferencias principales con nerdctl:

  • Runtime: podman usa crun/runc directamente, sin containerd. nerdctl usa containerd.
  • Daemon: podman es daemonless (cada comando crea los contenedores sin proceso persistente). nerdctl requiere containerd corriendo.
  • Kubernetes: podman puede generar manifests K8s (podman generate kube). nerdctl no.

Para equipos que viven en K8s, nerdctl suele encajar mejor porque reutiliza el runtime ya instalado. Para equipos en RHEL con flujos más independientes, podman es la opción natural.

Relacionado, ver cómo hemos hablado de Docker con Ubuntu 22.04 — los principios trasladan, solo cambia la capa CLI/engine.

Conclusión

nerdctl representa la maduración del stack de contenedores: separación limpia entre runtime (containerd), CLI (nerdctl), orquestador (K8s). Para entornos de desarrollo que quieren alinearse con producción K8s, o donde rootless es requisito, la transición paga. Para flujos donde Docker Engine funciona bien, no hay urgencia — pero vale conocer la alternativa.

Síguenos en jacar.es para más sobre contenedores, Kubernetes y herramientas de plataforma.

Entradas relacionadas